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I. 


INTRODUCTION 


This report summarizes the results of the collaborative project between NASA's 
Goddard Space Right Center and the Remote Sensing Systems Laboratory at the 
University of Maryland. The project was part of Goddard's ongoing development efforts 
towards the design of a Pilot Land Data System (PLDS) to support the land and 
atmospheric sciences. The PLDS project represents a multidisciplinary system 
development involving the sharing of design and development tasks between several 
NASA divisions and several key governmental and university institutions. 

The technical objective for the present University of Maryland’s collaboration was 
to provide research and development support to the Land Analysis software design efforts 
within the PLDS framework. The specific aim of the project was to develop within the 
PLDS software design environment, an easily implementable and user friendly geometric 
correction procedure to readily enable the georeferencing of imagery data from the 
Advanced Very High Resolution Radiometer (AVHRR) onboard the NOAA series 
spacecraft 

A key aspect in the PLDS development has been the close interaction between a 
preselected science scenario, the International Scienctific Land Science and Climatology 
Project (1SLSCP) and the actual systems development team. A benefit of this collaboration 
has been the avoidance of redundancy in design and the adoption of algorithms that have 
been found to be well tested by a large science user community. Accordingly, on 
recommendation by the PLDS Land Analysis Software development Task Team, the 
geometric correction subsystem was designed using the algorithm originally developed in a 
different system environment at the Johnson Space Flight Center (JSFC) by Lockheed 
Corporation. As originally implemented, the system was known as the Image Correction 
and Registration Utility System (ICARUS) and was only operable in a IBM environment 
with a minimum virtual memory of six megabytes. The ICARUS approach offers a simple 
and yet efficient means of mapping image data to earth coordinates. 

In order to address the technical goals of the present project, a software subsystem 
was developed within the guidelines set by the PLDS development environment utilizing 
NASA GSFC's Image Analysis Facility's (IAF) Land Analysis Software (LAS) coding 
standards. IAF's current program development environment, the Transportable 
Applications Executive (TAE) operates under a VAX VMS operating system and was used 
as the user interface. The developed software, relating to the georeferencing of AVHRR 
datasets, has been installed, tested and is now operating under LAS as three separate LAS 
functions - GSC_POINTS, GCS_GEOTAG, GCS.GRID. 

Subsequent to testing, the function GCS_GEOTAG has been transported to 
GSFC's Terrestrial Physics Division’s LTP system and is currently in routine use to 
support the geometric referencing of AVHRR image datasets required by the ongoing First 
ISLSCP Field Experiment (FIFE) project. FIFE is at present one of the projects currently 
selected to serve as a vehicle to test the overall system capabilities of the Pilot Land Data 
System. 

Section II of this report provides a brief overview of the ICARUS algorithm that 
has been implemented in the set of functions developed in this project period. A functional 
specifications description is provided in Section HI and finally, Section TV gives a list of 
the individual programs and directory names containing the source and executables installed 
in the IAF system. Appendix A-C provides a USER GUIDE in the LAS system 
documentation format for the three functions developed. 
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II. THE ICARUS APPROACH 


II. 1 The Geometry of the AVHRR Dataset 

The AVHRR dataset is obtained directly as a result of digitizing the analog data 
output from the sensors on board the spacecraft. The instantaneous field of view (IFOV) 
of each sensor is approximately 1.4 milliradians leading to a resolution at the satellite sub- 
point of 1.1 kms. for a nominal altitude of 833 kms. in a near "sub-synchronous" orbit. 
The scanning rate of the AVHRR is 360 scans per minute. At the sampling rate of 39„936 
samples per second per channel, there are 1.362 samples per IFOV. A total of 2048 
samples is obtained per channel per earth scan, which spans an angle of ±56 degrees from 
the nadir (sub-point view). 

The processor onboard the satellite also samples the real time AVHRR data to 
produce reduced resolution Global Area Coverage (GAC) data. Four out of every five 
samples along the scan line are used to compute one average value, and data from every 
third scan line is processed. All of the GAC data computed during a complete pass is 
recorded onboard the satellite for transmission to earth on command. 

The original 10 bit precision of the AVHRR data is transmitted from the satellite in 
real time (High Resolution Picture Transmission or HRPT data), and selectively recorded 
onboard the satellite for subsequent playback as Local Area Coverage (LAC) data. For the 
GAC data, the 10 bit data precision is retained but the resolution is degraded to 4.0 kms. 
along the scan line at the sub- point. 

The resultant image geometry is thus a two-dimensional array of digital brightness 
values in each of the wavelengths. The pixels are uniform samples along the cross-track 
direction while the orbital motion of the satellite produces the down track scan motion. 
Since no attempt is made to transform the sampled data to either a spacecraft centered 
(orbital scanner projection) or earth centered projection (any standard cartographic 
projection), the distributed GAC, LAC or HRPT datasets are distorted in the spatial sense. 


II. 2 Description of the ICARUS Algorithm 

The approach referred to as the ICARUS approach was originally designed at the 
Johnson Space Center and is a comprehensive geometric correction software system to 
process and georeference a number of different satellite imagery including the AVHRR. As 
originally implemented, the AVHRR geometric correction system requires a minimum 
available '/irtual memory of six megabytes. For the present development, the relevant 
portion of the algorithm for the forward/inverse transformation of AVHRR pixel-line 
locations to a geodetic coordinate system was obtained from a description of the ICARUS 
software and has been programmatically implemented. 

The ICARUS approach utilizes nominal spacecraft and earth related parameters and 
the assumptions are listed below: 

1 . The earth's surface is represented by an oblate spheroid with an assumed 
equatorial and polar radius; 

2. The spacecraft is in circular orbit with a fixed inclination angle and altitude; 
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3. The sensor has a uniform scan rate with a constant look-angle from nadir 
and points to the earth’s center; 

4. The precision rate of the line of nodes is uniform and is one inertial 
revolution per mean solar year, 

5. Atmospheric effects, terrain elevation effects and ground track curvature due 
to orbit perturbations are ignored; 

6. Variations in satellite altitude, orbital velocity, perturbations and non- 
spherical earth's surface are ignored. 

A comprehensive description of the ICARUS software is available separately 
(Boatwright et al., 1984), and the following is a brief review of the salient steps of the 
algorithm for mapping between image and geodetic latitude-longitude coordinates. 

The ICARUS approach relies on a selected tie-point for which both geodetic 
(latitude-longitude) and image coordinates (line, pixel) have been predetermined. 

A. Assume that the selected tie point lines on the surface of an oblate spheroidal earth. 

B. Construct an intersection sphere about the center of the earth and tangential to the 
spheroid at the tie point. 

C. A scanner map projection is then performed on this sphere: a U-axis (equator) is 
generated from the intersection of the inertial orbit plane of the satellite with this 
sphere; a V-axis (meridian) is defined by the intersection of the scan plane 
containing the tie point and the sphere. Thus, the U-V origin is at nadir of the scan 
containing the tie point. U-V Distances are measured in meters, positive 
northwards and eastward respectively. 

D. Points in the AVHRR scene are then related to U-V coordinates on the 'constructed' 
sphere by explicit models of the earth's rotation and scan curvature effects. 

E. Points on the earth are related to points on the 'constructed' sphere by geocentric 
projection in which the geocentric latitude is computed from the geodetic latitude. 


F. The conversion relations in both forward and inverse directions are analytic. 


III. FUNCTIONAL SPECIFICATIONS 

The AVHRR data is a cross track scanning system with five spectral channels. The 
resultant two-dimensional image is invariably associated with distortions due to the 
influence of the earth's rotation on the scanning geometry, panoramic distortions and earth 
curvature effects. The implementation of the ICARUS algorithm results in an output array 
of geodetic latitude- longitude coordinates corresponding to the locations of the pixels at the 
comers of a conceptual grid superimposed on the original image frame. The size of the 
grid shall be specified by the user in terms of number of pixels and scan line intervals using 
the leading top left comer of the image as the origin. The output array of gridded 
coordinates may also optionally serve as an ancilliary data file for subsequent data retrieval 
and or image resampling to any user desired cartographic projection. 
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The present version of the AVHRR geometric correction capability has been 
implemented on the IAF computer facility and is available under TAE as part of LAS. The 
programs have been written in DEC/VAX Fortran 77 under the VMS operating system. 

No VMS specific utilities have been implemented except those called under TAE controlled 
user interfacing. The disk resident input data to the geometric correction subsystem may be 
either HRPT (LAC) or GAC data. The format of input image data is expected to be in LAS 
image file format after the original GAC/LAC/HRPT dataset has been ingested through the 
PLDS data ingestion facility. 

The functional implementation of the ICARUS algorithm has resulted in three 
LAS/TAE functions: GCS_P01NTS, GCS_GEOTAG and GCS_GRID. The capabilities 
of the three functions are given below: 

o GCS_POINTS Given a user desired pixel location and 

scanline address, determine its corresponding 
latitude and longitude; alternatively, given a 
user input lat-long, the corresponding pixel- 
line location; the input is interactive, while the 
output is on screen and optionally to a disk 
resident session log file. 

o GCS_GEOTAG Generate a user desired grid of latitude- 

longitudes at user specified grid intervals of 
pixels and scan lines currently in a FIFE 
recommended format (this format will later be 
changed to a PLDS format). The present 
output is in two disk resident files, one for 
latitudes and the other for longitudes. 

o GCS_GRID Generate a mapping grid of coordinates in 

user specified output coordinate space (either 
AVHRR image space or geodetic coordinate 
space, i.e., latitude-longitude). 

A prerequisite to using any of the three functions is that the user is required to 
determine one preselected tie point coordinate in both image and geodetic coordinate space. 
Usually this is accomplished using an image processing facility at either the user's or the 
IAF's system. 

The user scenario for the use of the three functions are typically as follow's: 

1 . Point to a pixel on the AVHRR from an image display of the same, and 
determine its corresponding latitude-longitude - use GCSJPOINTS. 

2. Fix a geodetic latitude-longitude on a map and determine its corresponding 
pixel-line address on the original image frame - use GCS_POINTS. 

3. Input (rectangular) comer coordinates in pixel-line locations of a window in 
a AVHRR image, input pixel and line interval for a desired grid, and 
georeference (output latitude-ion gittude for) every corresponding grid 
intersection on the image - use GCS-GEOTAG. 
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4. Transform a selected image frame or rectangular image subset from original 
image space into a geodetic (lat-long) projection - Step I. use GCS_GRID 

Step II. use GEOM 

GCS_GRID creates the ancilliary mapping grid data required by LAS function GEOM as 
input. The output of GCS_GRID is, as described earlier, a mapping grid of coordinates, 
or a file of grid coordinates that reflect the mapping of AVHRR to geodetic coordinates. 

The mapping transformation applied by GEOM uses this data to perform the resampling. 
Thus GCS_GRID is required to be implemented only for geometric transformation of 
AVHRR imagery to latitude-longitude space. The grid may be generated over a user 
desired window in the original image frame and for a maximum grid size of 64x64 . 

In the event that GCS_GRID is being implemented for the purpose of invoking 
GEOM, it is essential to rememeber that the original image frame be checked for the 
direction of the pass. Since the origin of the image frame coordinate system is the bottom 
right corner of the frame for an ascending pass, the image must be flipped 180 degrees 
before using as input to tie-point selection or to GEOM. While the image coordinates as 
applied to the designed functions are always referrred to in full frame coordinates, it is 
possible to selectively input a part of the frame for actual geometric transformation using 
GEOM, and in this case, one may use screen coordinates (upper right comer - 1,1 : bottom 
right comer 512,512) to define the window. 

IV. SOFTWARE DIRECTORY 

The programs that have been supplied under the present contract are disk resident in 
the IAF system. The program modules are fortran coded subroutines and are linked 
together through a driver module for each of the three functions. 

The modules are as follows: 


User-interface Calls routine to handle the TAE interface and parameter 

handling 

Initialize Initializes parameters for geocentric (OSC) to AVHRR scene 

coordinate conversions 

AVOSC Performs conversion from AVHRR to OSC coordinates 

OSCAV Performs conversion from OSC to AVHRR scene pixel, line 

coordinates 

OSCLL Computes conversion from geocentric (OSC) coordinates to 

geodetic latitude-longitude 

LLOSC Computes latitude-longitude of pixel location within GAC, 

LAC or HRPT dataset 

These modules have been linked as appropriate within each of the three functions. 

Examples of the program logic are given below: 
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Function GCS_POINTS 

Program POINTS// 

Call user-interface 
Call initialize 

DO for every user input pixel location 

Case: Geodetic to AVHRR 
Call LLOSC 
Call OSCAV 


Endcase: 


Case: AVHRR to Geodetic 
Call AVOSC 
Call OSCLL 


Endcase: 


Enter output coordinate in session log file and on screen 

Enddo. 


End Program // 


Function GCS GEOTAG 


Program GEOTAG // 

Call user-interface 
Call initialize 

DO for every pixel location 

within user input window // window defined by pixel, line position 

Case: Geodetic to AVHRR 
Call LLOSC 
Call OSCAV 
Endcase: 

Case: AVHRR to Geodetic 

Call AVOSC 
Call OSCLL 
Endcase: 

Enter output coordinates in output files; 

Enddo. 

End Program // 
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Function GCS_GRID 

Program GRID // 

Call user-interface 
Call initialize 

DO for every user defined grid intersection 

Case: Geodetic to AVHRR 
Call LLOSC 
Call OSCAV 

Endcase: 

Case: AVHRR to Geodetic 
Call AVOSC 
Call OSCLL 

Endcase: 

Enter output coordinate in session log file and on screen: 

Enddo. 

End Program // 


Directory Contents: 

The source codes and executables are resident under the following subdirectories 
and filenames - 

CL$DU A3 : [ JOY. A VHRR_G CS .POINTS] TAE Usage- tutor POINTS 

BLD_POINTS.COM, COMPILE.COM, LINK.COM .. Command file to compile and 

link GCS_POINTS 

GCS_COMMONS.INC, GCS_DATA.1NC, GCS_DEF.INC, GCS_FUNC.INC 
GCS_TABLES.INC, GCS.VARIABLES.INC, IO.INC, MATH.CONSTANTS.INC , 
MSG.INC, OUT.INC, PARAMS.INC, TAE.INC, POINTS.HLP, POINTS.PDF 
DRIVER.FOR, USERJNTERFACE.FOR, GET.PARMS.FOR, INITIALIZE.FOR 
LLAVHRR.FOR, AVHRRLL.FOR, AVOSC.FOR, OSCAV.FOR, OSCLL.FOR, 
LLOSC.FOR, MSG_POINTS.MSG, POINTS.CMT, POINTS.EXE 

CLSDIJA3:f JOY. AVHRR GCS. GEOTAG1 TAE Usage- tutor GEOTAG 
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BLD_GEOTAG.COM , COMPILE.COM, LINK.COM .. Command file to compile and 

link GEOTAG. 

GCS_COMMONS.INC, GCS.DATA.INC, GCS_DEF.INC, GCS_FUNC.INC 
GCS.TABLES.INC, GCS_VARIABLES.INC, IO.INC, MATH_CONSTANTS.INC , 
MSG. INC, OUT.INC, PARAMS.INC, TAE.INC, GEOTAG.HLP, GEOTAG.PDF 
GEOTAG.FOR, 1NTERFACE.F0R, INITIALIZE.FOR, AVHRRLL.FOR, 
AVOSC.FOR , LATLON.FOR, GET_PARMS.FOR, 

OSCLL.FOR, GEOTAG.EXE, MSG.GEOTAG.MSG, 

POINtTS.CMT 

CL$DUA3:[J0Y.AVHRR_GCS.GRID] ; TAE USAGE- tutor GRID 

BLD_GRID.COM , COMPILE.COM, LINK.COM .. Command file to compile and link 

GCS_GRID 

G CS_COMMON S .INC, GCS_DATA.INC, GCS_DEF.INC, GCS.FUNC.INC 
GCS_TABLES.INC, GCS.VARIABLES.INC, IO.INC, MATH.CONSTANTS.INC , 
MSG.INC, OUT.INC, PARAMS.INC, TAE.INC, GRID.HLP, GRID.PDF 
GRID_DRIVER.FOR, USER_INTERFACE.FOR, GET_PARMS.FOR, 
INITIALIZE.FOR, AVOSC.FOR, OSCAV.FOR, OSCLL.FOR, LLOSC.FOR, 
MSG_POINTS.MSG, POINTS.CMT, GRID.EXE 
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V. 


CONCLUSION 


The project has resulted in the successful implementation of a practical technique to 
obtain in a timely manner, the geographic referencing of pixels contained in a full AVHRR 
scene frame. The programs have been implemented in fortran without implementing VAX 
specific code. Accordingly, the set of geometric correction routines may be transportable to 
smaller workstations easily. While most of the available methods result in a mapping from 
AVHRR scene to latitude-longitude only, the implemented algorithm in the present package 
allows the reverse mapping, lat-long to pixel, line - also. In consequence, the package has 
proved to be highly useful in supporting the day to day requirements of the FIFE project. 
The success of the program in the science scenario tests makes it attractive for adoption in 
the overall PLDS system capabilities. 
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Name: 

Function: 


PARAMETERS : 
OUT 

ID 


ISPACE 

OSPACE 


APPENDIX - ’A’ 


USER'S GUIDE 

POINTS 


GCS_POINTS generates the mapping from AVHRR 
image to geodetic latitude-longitude and vice 
versa. The output is placed on the screen and 
written to disk resident session log file. 

The purpose of this function is to allow the user 
the ability to transform a AVHRR image frame 
from its image frame coordinate system (LINE- 
PIXEL) to a geodetic projection. 


Name of outout report file, or 

User desired file name for outputting the mapping 
grid ( No default value; e.g., OUT = GRID.MAN ) 


NOAA spacecraft identifier ; 
for 

NOAA-7, ID = 3 
NOAA -8, ID = 4, etc. 

The present version of GCS_ POINTS contains 
spacecraft nominal orbit parameters for upto 
NOAA- 10. 

Input coordinate space; 

ISPACE = 2 for input image or image to be projected 

into lat-long space 

ISPACE = 1 for input in lat-lon 

Output coordinate space; OSPACE = 1 
specifies the direction of mapping or contents 


of the mapping grid to be in longitude coordinate. 
OSPACE=2 implies desired output 
in AVHRR image frame coordinates. 

TIELAT Latitude of tie point in deg. min. sec. 

Enter negative number for degrees for locations 
south of equator. 

TEELON Longitude of tie point in deg. min. sec. 

Enter negative degrees for images west of 
greenwich. 

TIEPIX Pixel location of tiepoint in full scene AVHRR 
line-pixel coordinates 

TIELIN Line number of of tie point in full scene 
AVHRR frame coordinates. 

* 

GCS_ POINTS requires that the user determine an appropriate 
tiepoint through an examination of the original AVHRR scene. It is 
not necessary that the selected tiepoint be within the image subset to 
be used for mapping. 


EXAMPLES: 


TAE > GCS_ POINTS= LOG. DAT ID=3 ISPACE=2 OSPACE=l 

TIELAT=14.0 17.0 20.0004 
TIELON= -16.0 55.0 59.988 
TIEPIX = 1026 TIELIN= 1150 
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APPENDIX - 1 B’ 


Name: 

Function: 


PARAMETERS : 
OUTLAT 
OUTLON 
CRAFTED 


USER'S GUIDE 

GEOTAG 


GCS_GEOTAG generates the mapping from AVHRR 
image to geodetic latitude-longitude and vice versa 
for a user selected window in either image frmae 
coordinates or latitude-longitude coordinates. The 
output is written to disk as two files- a file 
containing lattitude and a file containing longitude 
for respective pixels as specified in the window. 


The purpose of this function is to allow the user 
the ability to quickly georeference a AVHRR image 
frame from its image frame coordinate system 
(LINE-PIXEL) to a geodetic projection. (LAT-LON) 
for all pixels contained within a user specified 
image window in either an 
ascending or descending pass. 


Name of output report file of latitudes. 

Name of output file of longitudes. 

NOAA spacecraft identifier ; 
for 

NOAA-7, ID = 3 
NOAA-8, ID = 4, etc. 

The present version of GCS_ GEOTAG contains 
spacecraft nominal orbit parameters for upto 
NOAA- 10. 


ORBITDIR 


Direction of satellite orbit : 

A = ascending; D = descending pass; 


ISPACE Input coordinate space; 

ISPACE = 2 for input image or image to be projected 

into lat-long space 

ISPACE = 1 for input in lat-lon 

OSPACE Output coordinate space; OSPACE = 1 

specifies the direction of mapping or contents of 
the mapping grid to be in geodetic latitude- 
longitude coordinate. OSPACE=2 implies desired 
output in AVHRR image frame coordinates. 

TIELAT Latitude of tie point in deg. min. sec. 

Enter negative number for degrees for locations 
south of equator. 

T1ELON Longitude of tie point in deg. min. sec. 

Enter negative degrees for images west of 
greenwich. 

TIEPIX Pixel location of tiepoint in full scene AVHRR 
line-pixel coordinates 

TIELIN Line number of of tie point in full scene 
AVHRR frame coordinates. 

* 

GCS_GEOTAG requires that the user determine an appropriate 
tiepoint through an examination of the original AVHRR scene. It is 
not necessary that the selected tiepoint be within the image subset to 
be used for mapping. 


EXAMPLES: 


TAE > GCS_GEOTAG= LAT.DAT LON.DAT CRAFTID=3 ORBITDIR=A 
ISPACE=2 OSPACE=l 

TIELAT=14.0 17.0 20.0004 


TIELON= -16.0 55.0 59.988 
TIEPIX = 1026 TIELIN= 1150 


APPENDIX ’C’ 


USER'S GUIDE 

Name: GRID 


Function: GCS_GRID generates a file of grid coordinates that 

contains the mapping from AVHRR image to 
geodetic latitude-longitude. The output file from 
this function is used as an input to the LAS 
Geometric correction program GEOM. The output 
data file is also referred to as the user supplied 
mapping grid file in the GEOM user's guide. 

The purpose of this function is to allow the user the 
ability to transform a AVHRR image frame from its 
image frame coordinate system (LINE-PIXEL) to a 
geodetic projection. A mapping transformation is 
required to be applied to the original image through 
the use of the GEOM function. However, GEOM 
requires the availability of an appropriate mapping 
grid. GCS_GRID offers the user the means to 
generate this mapping grid using a single user 
supplied tie point. The mapping grid file, output 
from this function is used as an input to GEOM’s 
input parameter GRIN ( mapping grid file name ) 
and MAPMODE ( man: manually generated grid file). 


PARAMETERS : 

OUT Name of outout report file, or 

User desired file name for outputting the mapping 
grid ( No default value; e.g., OUT = GRID.MAN ) 


ID NOAA spacecraft identifier ; 

for 


NOAA-7, ID = 3 


NO A A -8, ID = 4, etc. 


The present version of GCS_GRID contains 
spacecraft nominal orbit parameters for upto 
NO A A- 10. 

ISPACE Input coordinate space; ISPACE = 2 for 
implementing GCS_GRID; 

ISPACE = 2 for input image or image to be projected 
into lat-long space specified in AVHRR original 
image space/line-pixel frame referencing. 

OSPACE Output coordinate space; OSPACE = 1 for 

this implementation of GCS_GRID; OSPACE = 1 
specifies the direction of mapping or contents of 
the mapping grid to be in geodetic latitude- 
longitude coordinate. 

TIELAT Latitude of tie point in deg. min. sec. 

Enter negative number for degrees for locations 
south of equator. 

TTELON Longitude of tie point in deg. min. sec. 

Enter negative degrees for images west of 
greenwich. 

TIEPIX Pixel location of tiepoint in full scene AVHRR 
line-pixel coordinates 

TIELIN Line number of of tie point in full scene 
AVHRR frame coordinates. 

* 

GCS_GRID requires that the user determine an appropriate tiepoint 
through an examination of the AVHRR scene to be reprojected to lat- 
lon domain prior to implementing GCS_GRID. It is not necessary that 
the selected tiepoint be within the image subset to be tranformed 
through GEOM. In addition, if the user desires to transform using the 
output of GCS_GRID as input to GEOM, it is advisable that the input 
AVHRR image be rotated 180 degrees using LAS function FLIP in 
those instances where the AVHRR dataset is from an ascending pass. 


EXAMPLES: 


TAE > GCS_GRID OUT=GRID.MAN ID=3 ISPACE=2 0SPACE=1 

TIELAT=14.0 17.0 20.0004 
TIELON= -16.0 55.0 59.988 
TIEPIX = 1026 TIELIN= 1150 


